Towards a Generic Anticipatory Agent Architecture for Mobile Robots

An anticipatory agent [1] is a hybrid agent which is able to predict changes of itself and its environment. Such agents prove interesting [2] [3] [4] in embedded systems such mobile robots. Indeed, they combine a reactive fast layer with a cognitive layer capable to perform corrective actions to avoid undesired situations before they occur actually. We present in this paper a generic architecture, that we plan to use as a guideline for developing anticipatory agents embedded into robots for search & rescue missions. Our approach relies on software components in order to explicit the anticipatory mechanisms. 1 Davidsson Quasi-Anticipatory Agent Architecture From the definition of Rosen [5], Davidsson defines a very simple class of anticipatory agent system: it contains a causal system S and a model M of this system that provides predictions of S. As the model M is not a perfect representation of the reactive system, this is called a quasi-anticipatory system. This architecture is rather coarse-grain. It is only composed of 5 parts: – Sensors: provide information about the agent environment. – Effectors: allow the agent to act upon its environment. – Reactor: drives the effectors in reaction to latest information provided by sensors. – WorldModel: is an abstract view of the agent’s environment based on data collected using sensors. – Anticipator: modifies the reactor to avoid undesirable predicted world state. 2 MALEVA: A Software Component Model Expliciting Data and Control Flows Software component [6] is a programming paradigm that aims at going beyond ObjectOriented programming from the point of view of modularity, reuse and improvement of ? This work is partially supported by the CPER TAC 2004-2006 of the region Nord-Pas de Calais and the european fund FEDER. software quality. Indeed, a software component is a software entity which explicits its dependencies and interactions with other components and resources it relies on. In this paper, we use the MALEVA hierarchical component model [7] in order to define and implement our anticipatory hybrid agent architecture. Indeed, MALEVA components are close to building blocks of the Brooks subsumption model in their encapsulation and interaction through data exchange [8]. A MALEVA component is a run-time software entity providing encapsulation like objects, while expliciting its interactions with other components. MALEVA components interact only through their interfaces. Interfaces can be of two kinds: data interfaces or control interfaces. Data interfaces are dedicated to data exchange, while control interfaces are dedicated to control flow. A component can be either active or passive. A passive component is a component that does perform some computation only after being triggered through one of its control input interfaces. Once the component computation is over, it stops until being again triggered. Contrary to a passive one, an active component don’t need to be triggered to act. It uses a thread in order to run autonomously. 3 Overview of our Generic Anticipatory Agent Architecture As shown on figure 1, our agent architecture is an assembly of five components: sensors, effectors, reactor, reaction ticker and anticipator. The first three parts (namely: sensors, effectors and the reactor) are application specific. However, the reactor is instrumented in order to provide two generic interfaces for modifications input: one for modification data flow and the second for modification control flow. The former allows the anticipator to provide modifications to be performed on the reactor, while the latter allows the anticipator to trigger the modifications. These two interfaces can be viewed as the socalled “meta-interfaces” in the work on Open Implementation [9], since they allow a disciplined modification of the reactor.